@khoa-nguyen-18 please explain a bit more about the advantages of this patch.

Currently, there is an issue related to storing the flash_hp API in RAM.
The current case is that some critical APIs of r_flash_hp cannot remain in ROM because, during the erasure of code flash, the APIs might also be erased. Therefore, we will store these critical APIs in RAM and place them in a sector defined in the linker as .code_in_ram.

Previously, when we defined it this way, it would be allocated right after the bss and noinit sections.
But a few days ago, there was a PR (zephyrproject-rtos/zephyr#74042) to move the bss and noinit sections for the Cortex-M series to the end of the linker script file. Since then, our .code_in_ram section has been unable to hold the content of the flash APIs. I suspect this is because the .code_in_ram section was not defined correctly. Therefore, I’ve decided to use the .ramfunc section which is already defined in the Cortex-M linker instead of using a custom-defined section.

@khoa-nguyen-18 , Since we've made change in the FSP library, could you please help to update the patch note the the README file

@khoa-nguyen-18 , Since we've made change in the FSP library, could you please help to update the patch note the the README file

I have updated it in README file